Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-187.txt

Text File | 1994-12-08 | 48.0 KB | 1,127 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 20 Oct 92       Volume 1 : Issue 187

Today's Topics:

    Patching the _Launch Trap
    GetColor bug (was RE: NON-QUICKDRAW GAMES)
    Palette Manager vs. Color Manager (was Re: NON-QUICKDRAW GAMES)
    The Pallette manager



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: John Champion <[e-mail]>
Subject: Patching the _Launch Trap
Organization: Arco Alaska Inc.
Date: Tue, 8 Sep 1992 02:40:49 GMT

Hi all,
I'm trying to install a fairly unobtrusive head patch into the _Launch
trap.  The problem is that no matter what I do, my patch always gets
re-patched (presumeably by the system).  This unknown code does not pass
control down the line like a normal patch would, so my code never gets
called.

I've tried patching at various times during startup to no avail.  If I
patch at init-launching time, my code gets called once (when Finder is
launched) and nevermore after that point.  If I patch after startup has
completed, then my patch gets re-patched before my code gets called even
once!

I'm using system 7, and I have no problem requiring it for my
application.  Does anyone have any ideas for getting around this
patch-happy little gremlin?  Thanks in advance for any advice.


- -John Champion      [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Leonard Rosenthol)
Date: Tue, 08 Sep 92 06:56:48 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> John Champion <[e-mail]> writes:
>Hi all,
>I'm trying to install a fairly unobtrusive head patch into the _Launch
>trap.  The problem is that no matter what I do, my patch always gets
>re-patched (presumeably by the system).  This unknown code does not pass
>control down the line like a normal patch would, so my code never gets
>called.
>
    Welcome to the wonderful world of "protected patches".  This is a
new trick in System 7 to make sure that programmers don't "screw up" system
patches.  It basically means that it is near impossible to patch such a trap.

    If you could post what you are trying to accomplish by patching _Launch
someone could probably suggest an alternate approach that would be successful.

- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician


+++++++++++++++++++++++++++

From: [e-mail] (John Champion)
Date: 8 Sep 92 14:51:00 GMT
Organization: Arco Alaska Inc.

In article <[e-mail]> Leonard Rosenthol,
[e-mail] writes:
>    Welcome to the wonderful world of "protected patches".  This is a
>new trick in System 7 to make sure that programmers don't "screw up"
system
>patches.  It basically means that it is near impossible to patch such a
trap.
>
>    If you could post what you are trying to accomplish by patching _Launch
>someone could probably suggest an alternate approach that would be
successful.

I need FSSpec type information on applications and associated documents
that are launched, particularly by the finder.  Unfortunately, not all
applications accept apple events so I can't just check for those.

- -John Champion      [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Leonard Rosenthol)
Date: 8 Sep 92 17:09:43 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> John Champion <[e-mail]> writes:
>In article <[e-mail]> Leonard Rosenthol,
>[e-mail] writes:
>>
>>    If you could post what you are trying to accomplish by patching _Launch
>>someone could probably suggest an alternate approach that would be
>successful.
>
>I need FSSpec type information on applications and associated documents
>that are launched, particularly by the finder.  Unfortunately, not all
>applications accept apple events so I can't just check for those.
>
    Well, finding applications are easy, but getting documents may be a
bit difficult since they are not "launched".

    One way that might work, assuming that you only care about System 7
would be to intercept 'osel' events in the Finder.  When the Finder "opens"
anything, file, folder, disk, etc. it will send itself an 'osel' event - also
many launching utils will also send the same event to the Finder in order to
have things opened.

    There are two ways to intercept Apple events.  The hard way is to patch
_Pack8 (Apple Event manager), the easy (but undocumented way) is to install
something called a PHAQHandler.  A PHAQHandler is the equivalent of a head
patch on an Apple event handler, so you could just grab the data for the event
and then pass it along.  You might also be able to do the same thing by
getting the address of the current 'osel' handler, installing your own and
then calling the original...

- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Organization: Taligent
Date: Tue, 8 Sep 1992 21:33:29 GMT

In article <[e-mail]>, [e-mail] (Leonard
Rosenthol) writes:
>
> In article <[e-mail]> John Champion <[e-mail]>
writes:
> >Hi all,
> >I'm trying to install a fairly unobtrusive head patch into the _Launch
> >trap.  The problem is that no matter what I do, my patch always gets
> >re-patched (presumeably by the system).  This unknown code does not pass
> >control down the line like a normal patch would, so my code never gets
> >called.
> >
>     Welcome to the wonderful world of "protected patches".  This is a
> new trick in System 7 to make sure that programmers don't "screw up" system
> patches.  It basically means that it is near impossible to patch such a trap.
>

The problem with patching _Launch is not that it's protected. You can patch
protected patches; you just won't be the first in the chain when you're done.

The problem with patching _Launch is that it is patched after INIT time, and
doesn't call the original trap. You'd have the same problem with other traps as
well, notably Window Manager traps.


In article <[e-mail]> John Champion <[e-mail]>
writes:
>In article <[e-mail]> Leonard Rosenthol,
>[e-mail] writes:
>>
>>    If you could post what you are trying to accomplish by patching _Launch
>>someone could probably suggest an alternate approach that would be
>successful.
>
>I need FSSpec type information on applications and associated documents
>that are launched, particularly by the finder.  Unfortunately, not all
>applications accept apple events so I can't just check for those.
>

I do something like this. I patch InitGraf right now, but I'm considering a
scheme where I patch InitAllPacks, instead. The problem with patching InitGraf
is in determining if the call is being made from the start of an application.
Some InitGraf calls are made from INITs at INIT time (by ShowINIT, for example);
some applications call InitGraf more than once (applications written with THINK
Pascal are common "offenders"); and CE Toolbox calls InitGraf at shutdown time
under certain circumstances. If you patch InitGraf, you'll have to look out for
all these cases.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Bill Williams)
Organization: HoloNet (BBS: 510-704-1058)
Date: Wed, 9 Sep 1992 05:04:39 GMT

>It basically means that it is near impossible to patch such a
trap....

I am not positive but two years ago at MacHack during the forum discussing
"the correct way to write any kind of INIT" that was headed by several
Apple employees, I could have sweared that I thought I heard a panelist
mention that there was a reserved way to patch than involved setting a
value in memory. I vaguely feel that it was setting a LoMem to a special
value befor calling SetTrapAddress or something higher up on the stack.

Anyway I'll bet Apple has some official ways to patch just about anything
in system seven internally. Or at least I'd wish they did.

BWilliams


+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 10 Sep 92 06:49:36 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <gvrn-n#[e-mail]>, [e-mail] (Leonard Rosenthol) writes:

>     One way that might work, assuming that you only care about System 7
> would be to intercept 'osel' events in the Finder.  When the Finder "opens"
> anything, file, folder, disk, etc. it will send itself an 'osel' event - also
> many launching utils will also send the same event to the Finder in order to
> have things opened.
>
>     There are two ways to intercept Apple events.  The hard way is to patch
> _Pack8 (Apple Event manager), the easy (but undocumented way) is to install
> something called a PHAQHandler.  A PHAQHandler is the equivalent of a head
> patch on an Apple event handler, so you could just grab the data for the event
> and then pass it along.  You might also be able to do the same thing by
> getting the address of the current 'osel' handler, installing your own and
> then calling the original...

This may work with Finder 7.1 (not that I've seen it), but it certainly won't
work with Finder 7.0. Finder 7.0 doesn't use the Apple Event Manager for doing
its own event handling, so it's no good trying to intercept Finder events by
doing anything to or with the Apple Event Manager. Not from within the Finder's
process context, anyway. You'll have to patch AcceptHighLevelEvent.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
This line intentionally left unfunny.

+++++++++++++++++++++++++++

From: [e-mail] (Jeremy Roussak)
Date: 9 Sep 92 17:21:36 GMT
Organization: Computer Science Dept, QMW, University of London

In <[e-mail]> [e-mail] (Keith Rollin) writes:

>I do something like this. I patch InitGraf right now, but I'm considering a
>scheme where I patch InitAllPacks, instead. The problem with patching InitGraf
>is in determining if the call is being made from the start of an application.
>Some InitGraf calls are made from INITs at INIT time (by ShowINIT, for example);
>some applications call InitGraf more than once (applications written with THINK
>Pascal are common "offenders"); and CE Toolbox calls InitGraf at shutdown time
>under certain circumstances. If you patch InitGraf, you'll have to look out for
>all these cases.

The other problem with patching _InitGraf is that it doesn't
move memory, so neither can (should) your patch. We won't get
into the "all traps move memory because of patches" here! You
can argue that unexpectedly moving memory within _InitGraf
probably won't matter because of the way in which apps call it,
but it's a little unsafe. _InitFonts, on the other hand, does
move memory and is usually called immediately after _InitGraf.

When is _InitAllPacks called?

Jeremy

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 10 Sep 92 05:59:50 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Jeremy
Roussak) writes:
>
> In <[e-mail]> [e-mail] (Keith Rollin) writes:
>
> >I do something like this. I patch InitGraf right now, but I'm considering a
> >scheme where I patch InitAllPacks, instead. The problem with patching
InitGraf
> >is in determining if the call is being made from the start of an application.
> >Some InitGraf calls are made from INITs at INIT time (by ShowINIT, for
example);
> >some applications call InitGraf more than once (applications written with
THINK
> >Pascal are common "offenders"); and CE Toolbox calls InitGraf at shutdown
time
> >under certain circumstances. If you patch InitGraf, you'll have to look out
for
> >all these cases.
>
> The other problem with patching _InitGraf is that it doesn't
> move memory, so neither can (should) your patch. We won't get
> into the "all traps move memory because of patches" here! You
> can argue that unexpectedly moving memory within _InitGraf
> probably won't matter because of the way in which apps call it,
> but it's a little unsafe. _InitFonts, on the other hand, does
> move memory and is usually called immediately after _InitGraf.

You make a good point concerning patching _InitGraf. I had thought about it at
the time, but went ahead and patched it, figuring that I was safe for the
reasons you gave.

>
> When is _InitAllPacks called?
>

After your application is loaded, but just before its entry point is called.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Jeremy Roussak)
Date: 10 Sep 92 17:54:27 GMT
Organization: Computer Science Dept, QMW, University of London

In <[e-mail]> [e-mail] (Keith Rollin) writes:

>In article <[e-mail]>, [e-mail] (Jeremy
>Roussak) writes:
>>
>> The other problem with patching _InitGraf is that it doesn't
>> move memory, so neither can (should) your patch. We won't get
>> into the "all traps move memory because of patches" here! You
>> can argue that unexpectedly moving memory within _InitGraf
>> probably won't matter because of the way in which apps call it,
>> but it's a little unsafe. _InitFonts, on the other hand, does
>> move memory and is usually called immediately after _InitGraf.

>You make a good point concerning patching _InitGraf. I had thought about it at
>the time, but went ahead and patched it, figuring that I was safe for the
>reasons you gave.
>>
>> When is _InitAllPacks called?
>>

>After your application is loaded, but just before its entry point is called.

Are you sure this is correct? I just tried trapping with
MacsBug on _InitAllPacks: the file dcmd fails to show that the
application's resource file is open, CurMap is
FinderPreferences and CurApRefNum is the Finder. (SE/30, 7.0
tuned). If the app's resource file isn't available, it's tricky
to find it's details. CurApName is correctly set up, though.

Jeremy

---------------------------

From: [e-mail] (John Miller)
Subject: GetColor bug (was RE: NON-QUICKDRAW GAMES)
Date: 9 Sep 92 20:46:59 GMT
Organization: MIND LINK! - British Columbia, Canada

In article <[e-mail]>,
Ben Haller ([e-mail]) writes
>  BTW, anybody noticed the charming System 7 bug that when the
> Color Picker comes up, after you dismiss it it leaves the CLUT
> fucked up?  Charming.  They haven't fixed that one yet, have they?

Yep.  Been meaning to post a message about that for months
now.  Haven't tried Apple's latest color stuff, but as of
Tuned-up System 7, the bug was still there.  Didn't
occur under System 6 with or without 32-Bit QuickDraw.

Rather annoying behaviour for a call that is documented to put
everything back the way it was.  Fortunately, writing an
crude alternate color dialog for CLUT devices was quick
enough, but it was an frustrating last minute discovery.

(I had a good excuse for not using the Palette Manager.
I was colorizing HyperCard's stack window.  The Palette
Manager doesn't think that attaching a palette to a
B&W window is a very groovy idea.)

I guess Apple engineers only use 24-bit displays these days.
Goes along with those 2 gigabyte disk drives and 64 Meg
of RAM they use for running MPW/CFront/MacApp/OtherNeatTools.  :) :)

John Miller
Symplex Systems

+++++++++++++++++++++++++++

From: [e-mail] (Brad Fowlow)
Date: 10 Sep 92 17:26:37 GMT
Organization: Visual Edge Software, St. Laurent, Quebec

[e-mail] (John Miller) writes:
: In article <[e-mail]>,
: Ben Haller ([e-mail]) writes
: >  BTW, anybody noticed the charming System 7 bug that when the
: > Color Picker comes up, after you dismiss it it leaves the CLUT
: > fucked up?  Charming.  They haven't fixed that one yet, have they?
: ....
: Rather annoying behaviour for a call that is documented to put
: everything back the way it was.  Fortunately, writing an
: crude alternate color dialog for CLUT devices was quick
: enough, but it was an frustrating last minute discovery.

An observation:

It restores things, but in the palette manager's terms;
after the dialog goes away, the palette manager is free to
satisfy the color requirements of the next FrontWindow.

One thing folks (or else I) seem to have missed
is what is promised for a window without a palette.
The color environment for a color window without a palette
isn't the "normal" system palette, it's black and white,
and a gray and the highlight color if possible;
other colors get matched at the convenience of the PM.

So the dismiss behaviour of the color picker
is (sort of) a good thing; the palette manager
is reducing the amount of window refresh by changing
the color env only so far as it must to meet the stated
requirements of the front window.


A question:

I don't see how to change this behavior without going under the PM.
That is, I can't see how to kick the palette manager into using
a palette without using a window that the palette is attached to.

For example,
I have (in an app) zero or more open windows each with its
own palette.  Switching among these windows is a rock video,
but they do get updated quite well. After closing the
last window, its color env stays around, because there's no
other window demanding its own colors.   Quitting the application
seems to kick the PM into restoring the "normal" color env
(perhaps the Finder is doing this?).   I'd like this
to happen whenever a last window closes.

But I don't see how to get the PM to change the color environment
without having a window active and setting its Palette.
As long as the app is running, the pm won't retire that
last window's colors until forced by another paletted window,
and as we've noticed, there aren't many of those.

Any thoughts on a PM-friendly way to get back the "normal"
system palette when my last paletted window dies,
just as happens when the app quits?

- - brad

- --
- -------------------------------------------------------------
 Brad Fowlow   [e-mail]     Visual Edge Software Limited

+++++++++++++++++++++++++++

From: [e-mail] (Joe Francis)
Date: 11 Sep 92 00:59:24 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Brad Fowlow) writes:

> Any thoughts on a PM-friendly way to get back the "normal"
> system palette when my last paletted window dies,
> just as happens when the app quits?

I'm hopeful that someone else will post a more elegant way, but one way
to do what you want is to detect when you are closing your only window,
EraseRect it's portRect, and set it's Palette to the system palette,
*then* close the window.

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Fri, 11 Sep 1992 17:12:07 GMT

[e-mail] (Joe Francis) writes:
>[e-mail] (Brad Fowlow) writes:
>
>> Any thoughts on a PM-friendly way to get back the "normal"
>> system palette when my last paletted window dies,
>> just as happens when the app quits?
>
>I'm hopeful that someone else will post a more elegant way, but one way
>to do what you want is to detect when you are closing your only window,
>EraseRect it's portRect, and set it's Palette to the system palette,
>*then* close the window.

On the puzzle page in develop #11 (available from ftp.apple.com), Kon &
Bal write: "In 32-Bit QuickDraw David Van Brink extended the Palette
Manager to include a routine called PaletteMgrExit. This routine is
called automatically for you when your application quits, thus restoring
the default color state."

Macsbug doesn't know that word, but you might want to try snooping
around (maybe step through ExitToShell, not that I'd like to try it).
Maybe you could shut down and re-init the Palette Manager?

Somehow I doubt that using an undocumented trap qualifies as an
"elegant" solution, but I thought I'd pass it along...
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 The essence of OOP:  "After some hacking, I finally got the program to
 work, but I'm still not sure why." - David Marcovitz ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Humayun Lari)
Date: 12 Sep 92 20:31:09 GMT
Organization: The University of North Carolina at Chapel Hill

In article <[e-mail]> [e-mail] (Joe Francis) writes:
>In article <[e-mail]>
>[e-mail] (Brad Fowlow) writes:
>> Any thoughts on a PM-friendly way to get back the "normal"
>> system palette when my last paletted window dies,
>> just as happens when the app quits?
>I'm hopeful that someone else will post a more elegant way, but one way
>to do what you want is to detect when you are closing your only window,
>EraseRect it's portRect, and set it's Palette to the system palette,
>*then* close the window.

How about this: close the window and then create a new window offscreen (i.e.
with coordinates like 32000, 32000, 32010, 32010) Set its palette to the system
palette, and the Palette Manager should do its job... or is it smart enough to
check whether the window is onscreen? I'd test this, but I'm at school.

BTW, shouldn't the palette be a pure black-and-white palette, so as to be nice
to the applications in the background? Or will this not work?

Humayun Lari
([e-mail])

---------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject: Palette Manager vs. Color Manager (was Re: NON-QUICKDRAW GAMES)
Date: 10 Sep 92 18:21:47 GMT
Organization: Kalamazoo College

(Sorry to the csmp folks who are tiring of this thread;  I think this
article is relevant enough to be of interest to some programmers.)

[e-mail] (Ben Haller) writes:
>
>In my experience using the palette manager means the screen does CLUT
>flashes that are even more distracting than they would usually be (i.e.
>it will often flash *several times*)

With all deference to your experience--I love the two games of yours
that I've seen--I think your bad impressions are due to not using the PM
for a long time, and to badly-behaved applications (such as yours :-).

I'm right now flipping back and forth between my app and GIFConverter
(which uses the P.M.).  The clut changes exactly once, and each app
redraws its window for the new color environment exactly once.  (Well,
mine does it twice, but that's debugging code I haven't taken out yet.)
With lots of windows, it takes a few seconds, but so do all
mass-updates; what do you expect?

>the other applications
>in the system are often permanantly fucked up and don't redraw correctly
>from then on.

You may be thinking specifically of the Finder, which is courteous to
the point of obsequiosity.  If its icon colors aren't immediately
available, it doesn't even try to get them;  it just reverts to black
and white.

Applications that use the P.M. properly will get the colors they
request.  Those that don't, won't.

>Nobody else uses the Palette
>Wrecker, and so all of the much-touted benefits simply aren't there (lack
>of entry conflicts with other apps, etc.)
>[later...]
>what proportion of commercial apps do you suppose use
>the Palette Manager?

I'd guess 90% of them, at least.  Those that don't cause conflicts.  For
example, our staff artist uses Studio/8, which uses the Color Manager.
It doesn't happen very often, but every once in a while, you'll notice
that after quitting, the inverse table is out of sync--the Finder's
icons are screwed up, some text prints in funny colors, and so on.  Only
restarting fixes it.  And if you hate color flashes on context switches,
try flipping in and out of Studio/8 a few times.

Same for those apps of mine that use the C.M.  It's totally unpredictable,
and affects any system or machine.  I still have no idea what I did wrong.

Solarian II and Lunatic Fringe take over the whole screen.  Try putting
them in a window, and doing context switches like a good little app.
Not during game play, of course--just so I can start and keep track of a
download between games, without having to quit.  Suddenly the C.M. isn't
so useful, is it?  Unless your users like everything behind your window
appear in truly bizarre colors.

Then, keep in mind what you have to do to prevent background apps from
coming forward.  Sure, you just don't react to clicks on the desktop.
But remember those FKEYs that call OpenDeskAcc()?  OK, you have to set
that byte at ScrnDmpEnable--er, or do you clear it?  Now no one can
cmd-shift-3 a snapshot of the game in action, and the boss wants a .GIF
to put on the box ten minutes ago...

It's just not worth it.

>And it has a lot of drawbacks,
>not the least being that's it's slow, it increases your code size,

It's as slow as it takes apps to redraw for a new color environment.
Code size does not increase appreciably (though 'pltt' resources take up
twice as much room as 'clut's, caveat ResEditer).

>it looks worse,

Oh come on!  Colors are colors.

>and it's (in my opinion) meither as aesthetically pleasing
>nor as compatable as just saving & setting the CLUT (or part of the CLUT)
>on resume events and restoring the parts you changed on suspend events.

And in my opinion it's a thousand times easier and more compatible.

>  Also, if you're using direct-to-screen as almost everyone does - in a
>pixel-oriented paint program or in a video game - then you'll want the
>whole CLUT to yourself

How many games do you know that really, really _need_ 256 colors--not
254 or 255 but 256?  If you're clut-flipping to simulate page-flipping,
OK;  if you're writing for a 2-bit-deep screen, I can see that.  Most
games get along fine with 254 colors.

Paint programs...well, Studio/8 uses the Color Manager and it _still_
doesn't let you edit black and white.

>[in a later article...]
>*But* - when another
>application that doesn't use the Palette Manager *or* SetEntries get
>brought to front, the environment is not restored.  The other applications
>palette stays in place, and the app that wanted the system palette is
>fucked (pardon the expression).

Wait a minute.  If your app wants the system palette, attach a clone of
the system palette to its windows.  If you don't care what colors you
have, what's the problem?

>But IMV-152 says "If the front window is an old-style window,
>or if it has no assigned palette, the Palette Manager establishes the color
>environment using a default palette.  For many simple application the
>default palette will suffice."  To me this implies that you are supposed
>to be more or less guaranteed the system palette unless you request
>something else.  It doesn't seem to work this way.

You were supposed to rip that chapter out when you got IM VI.  :-)  That
phrase is nowhere to be found now, having been replaced by "By creating
a palette of colors for your application, you ensure that appropriate
colors are available when its window becomes frontmost."

By "many simple applications" is meant "applications that only want
black and white, and don't really care too much whether they get their
other colors or not."

>BTW, anybody noticed the charming System 7 bug that when the Color Picker
>comes up, after you dismiss it it leaves the CLUT fucked up?  Charming.
>They haven't fixed that one yet, have they?

Nope;  but at least the Color Picker chapter no longer promises "it will
not alter the clut."  That's another chapter you should have ripped out
of IM V.  :-/

>There is nothing wrong with SetEntries - at least
>nothing that the Wrecker fixes.  So why bother.

Except color arbitration with the large majority of apps that _do_ use
the Palette Manager.  Except having to worry about ctSeeds and iTabSeeds;
when to re-make the inverse table (do you have to after SetEntries?
RestoreEntries? will Color2Index do it for you?);  sequence vs. index
mode in SetEntries;  how to use your source-level debugger when you've
set colors 0 and 255 to black...  Hey, three years ago I thought the
Color Manager looked easier, and I wrote three games with it.  We
still get about one tech call a week, "why does my text draw in aqua
after I quit your game?"

The Palette Manager is the right choice for 99% of the apps out there--
the 1% being those games which take over an entire screen, don't have a
menubar, _and_ which truly need _every_ color in the table.  At present,
I know of exactly one game which fulfills all three conditions.  (Storm,
because it uses clut flipping.)


If you followup, please edit the Followup-To line appropriately.  Thanks.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "Don't listen to Jamie, he averages several lies per message, especially when
  they are directed towards me or are talking about me, this BBS, 'Holocaust
  Deniers', etc.  I'm ignoring him now."   - Dan "Maynard" Gannon, 23 Aug 1992

+++++++++++++++++++++++++++

From: [e-mail] (Ben Haller)
Date: 11 Sep 1992 01:10:06 GMT
Organization: Stick Software

[there is a lot in this posting that I'm replying to that had already
been addressed in the prior discussion, so with all due respect, I'm
deleting it...]

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>[e-mail] (Ben Haller) writes:
>>Nobody else uses the Palette
>>Wrecker, and so all of the much-touted benefits simply aren't there (lack
>>of entry conflicts with other apps, etc.)
>>[later...]
>>what proportion of commercial apps do you suppose use
>>the Palette Manager?

>I'd guess 90% of them, at least.  Those that don't cause conflicts.  For
>example, our staff artist uses Studio/8, which uses the Color Manager.
>It doesn't happen very often, but every once in a while, you'll notice
>that after quitting, the inverse table is out of sync--the Finder's
>icons are screwed up, some text prints in funny colors, and so on.  Only
>restarting fixes it.  And if you hate color flashes on context switches,
>try flipping in and out of Studio/8 a few times.
  First: 90% is way high.  That's simply not reality, IMHO.  I could
be wrong, but I have *serious* doubts about that estimate.  (of couse,
both of us are just talking out of our ass, so whatever...)
  Second: the inverse table being out of synch, etc., has nothing
to do with the Color Manager.  I mean, the Palette Manager *uses*
the Color Manager, no?  So how could it possibly be a bug in the
Color Manager, and yet not be exhibited in PM apps?  No lo comprendo.
  Third: Studio/8 would flash if it used the PM, too.  That's just
the reality of using the whole CLUT.  Life sucks sometimes.

>Same for those apps of mine that use the C.M.  It's totally unpredictable,
>and affects any system or machine.  I still have no idea what I did wrong.
  Well, neither do I, but I can assure you my apps work fine.

>>  Also, if you're using direct-to-screen as almost everyone does - in a
>>pixel-oriented paint program or in a video game - then you'll want the
>>whole CLUT to yourself
>How many games do you know that really, really _need_ 256 colors--not
>254 or 255 but 256?  If you're clut-flipping to simulate page-flipping,
>OK;  if you're writing for a 2-bit-deep screen, I can see that.  Most
>games get along fine with 254 colors.
  The thread has already discussed the problem with using the Palette
Manager to get even 254 colors.
  Please, pay attention.  I just deleted about forty lines of your post
that showed even less attention to thread history than this.  Ok, sorry,
flame off.  But really, I hate repetitive threads...

>Paint programs...well, Studio/8 uses the Color Manager and it _still_
>doesn't let you edit black and white.
  Studio/8 is pathetic.  Lay off the poor thing already.

>Wait a minute.  If your app wants the system palette, attach a clone of
>the system palette to its windows.  If you don't care what colors you
>have, what's the problem?
  This has also been discussed.  It slows down CopyBits.  Read up, mate!

>You were supposed to rip that chapter out when you got IM VI.  :-)  That
>phrase is nowhere to be found now, having been replaced by "By creating
>a palette of colors for your application, you ensure that appropriate
>colors are available when its window becomes frontmost."
> ...
>Nope;  but at least the Color Picker chapter no longer promises "it will
>not alter the clut."  That's another chapter you should have ripped out
>of IM V.  :-/
  How come they keep changing the only parts I *like*??!?

>Except having to worry about ctSeeds and iTabSeeds;
>when to re-make the inverse table (do you have to after SetEntries?
>RestoreEntries? will Color2Index do it for you?);  sequence vs. index
>mode in SetEntries;  how to use your source-level debugger when you've
>set colors 0 and 255 to black...
  SetEntries changes the ctSeed for you, which causes the ITable to
be rebuilt for you.  If you really *want* to you can do the
rebuilding yourself, though, I guess.  If you're a glutton for
punishment...
  I *like* sequence vs. index mode.
  And I never use source-level debuggers.  Besides, I have a secondary
monitor.  :->

>  Hey, three years ago I thought the
>Color Manager looked easier, and I wrote three games with it.  We
>still get about one tech call a week, "why does my text draw in aqua
>after I quit your game?"
  Well, that's your game.  SolII works fine, LF works fine, Satori and
Mountains and all the other AD modules I've written that call SetEntries
work fine...  What's the problem with *your* code?
  I've never seen anyone defend a crappy piece of code like the
Palette Manager by saying that code they wrote a few years ago
that didn't use it was buggy...

>The Palette Manager is the right choice for 99% of the apps out there--
>the 1% being those games which take over an entire screen, don't have a
>menubar, _and_ which truly need _every_ color in the table.  At present,
>I know of exactly one game which fulfills all three conditions.  (Storm,
>because it uses clut flipping.)
  Oh, nonsense.  Get a life.  How about: anything that doesn't use
a window.  Anything that needs more precise control, or greater speed,
than the Palette Manager gives you?  Anything written by someone who
doesn't feel like wasting their time using a high-level, buggy,
annoying manager to do something when there's a perfectly well-documented
and supported way of *avoiding* the damn thing?  Really, see if you
can get your DTS fever a little more stoked up!

>If you followup, please edit the Followup-To line appropriately.  Thanks.
  Well, I took out alt.religion.computers or some such group that I've
never even *heard of* before.  Is that what you wanted me to do?
  You also mistyped "programmer" in "comp.sys.mac.programmer" - you
added an extra "ers" on the end.  I have no idea why your posting
software didn't bark - mine sure did, four times!

  Sorry if this message is a little flaming, but really, it's annoying that
you seem to have completely ignored half of the point of all the previous
messages in this thread.

- -Ben Haller ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Susan Margarit)
Date: 12 Sep 92 04:18:14 GMT
Organization: NMSU Computer Science

BH> Sorry if this message is a little flaming, but really, it's
annoying....

Say, didn't I read about you recently? Something about spitting on
State Department or Apple DTS faxes and playing games in a war zone?
Or was that another games genius with an attitude...  ;)

  Jim Margarit

+++++++++++++++++++++++++++

From: [e-mail] (Ben Haller)
Date: 13 Sep 1992 00:46:35 GMT
Organization: Stick Software

In article <[e-mail]>
  [e-mail] (Susan Margarit) writes:
>Say, didn't I read about you recently? Something about spitting on
>State Department or Apple DTS faxes and playing games in a war zone?
>Or was that another games genius with an attitude...  ;)

  Hmm.  I dunno, where did you read it?  I certainly hate the
State Department, but I haven't been near enough to it to spit
on it recently.  I never fax to DTS, or indeed deal with DTS in
any way.  Playing games in a war zone?  Well, inasmuch as the US
(and Berkeley in particular) is a war zone, this makes perfect sense.
  Magazines never *tell* you that they've written an article on
or mentioning you, so I probably am not aware of most of the things
that get said about me in the press.  I wish they had better manners -
they could at least send me a copy if they mention me...just so
I can at least sue them for libel :->
  BTW, I don't know why you posted this, so I posted back.  Take it
to e-mail unless you have a reason not to...

- -Ben Haller ([e-mail])

---------------------------

From: [e-mail] (Matthew Hall)
Subject: The Pallette manager
Date: 8 Sep 92 20:58:08 GMT
Organization: Oberlin College Computer Science


I have a question that's not directly related to the games thread, but
its close.

I am drawing a 256 color plot in an offscreen pixmap.  I set the
offscreen pmtable to whatever clut I wish to choose.  Then, from that
I creat a palette optimized for the current color level (or none for
direct devices).  So, if I'm in 16 colors, I would take one of every
16 colors in the 256 color clut that I loaded in (with black and white
appropriately placed) and place them in the palette. Then I set the
app's default palette to this new palette.
 This way, I can
draw directly into the offscreen map since the positions of the colors
in the clut don't change, and I don't have to use
pmtolerant+pmexplicit, or setentries, and I can draw in an ideal color
environment and let PM take care of tolerance and updates.  Now - two problems

It runs very oddly in the system 7 finder.  Sometimes the menus are
dimmed by gray color, sometimes by gray pattern.  When I switch to the
finder, sometimes dimmed menus are displayed as an attrocious shade of
magenta.  I guess in the previous thread it says that the finder is
"courteous to the point of obsequity", but magenta menus?

Also, I want to create a black background offscreen, I switch to the
offscreen port.  I call a fillrect (backpat=black,backcolor=0,0,0);
and then copybits to the screen.(with the window as the current port)
At this point, the cluts first and last entries are white and black
respectively.  If I am in an indexed environment, everything is
hunky-dory. If I am in a direct environment, the background stays
white, and if I switch between the two, I usually get a cyan  (one of
the earlier entries in my clut).
 Now when I draw direct (plug index values in the data) into the
pixmap, and copybits to the screen
everything is fine. $FF turns to black, etc.  So the problem seems to
be that fillrect is placing the (teh) wrong index into the pixmap.  Is
this because my offscreen port is using the current gdevice, and
thinks black is somewhere else in my clut than it actually is? If so,
do I have to create a new gdevice for the pixmap?
Actually, is my method compatible? Is it stupid?  and why the strange
problems.

Any help appreciated,
- -matt hall
- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 11 Sep 92 18:18:06 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Matthew Hall) writes:
>
> I am drawing a 256 color plot in an offscreen pixmap.  I set the
> offscreen pmtable to whatever clut I wish to choose.  Then, from that
> I creat a palette optimized for the current color level (or none for
> direct devices).  So, if I'm in 16 colors, I would take one of every
> 16 colors in the 256 color clut that I loaded in (with black and white
> appropriately placed) and place them in the palette. Then I set the
> app's default palette to this new palette.

An easier way might be to use the pmInhibit flags. That way you can specify
for each palette entry which screen depths to use it at, and you don't have
to check the screen depth before setting up your palette.

>  This way, I can
> draw directly into the offscreen map since the positions of the colors
> in the clut don't change, and I don't have to use
> pmtolerant+pmexplicit, or setentries, and I can draw in an ideal color
> environment and let PM take care of tolerance and updates.

Hang on--you don't need a palette for an offscreen port. The main point of
palettes is for use with on-screen windows. The only point with attaching
a palette to an offscreen port would be so you can use PmForeColor and
PmBackColor to quickly specify colours from the palette. Tolerant and
animated entries don't mean anything in an offscreen palette.

[problems with on-screen display omitted]

>  Now when I draw direct (plug index values in the data) into the
> pixmap, and copybits to the screen
> everything is fine. $FF turns to black, etc.  So the problem seems to
> be that fillrect is placing the (teh) wrong index into the pixmap.  Is
> this because my offscreen port is using the current gdevice, and
> thinks black is somewhere else in my clut than it actually is? If so,
> do I have to create a new gdevice for the pixmap?
> Actually, is my method compatible? Is it stupid?  and why the strange
> problems.

What exactly *is* your method? If you're directly poking colour table
entries, are you remembering to call CTabChanged so QuickDraw knows what
you've been up to? If you want a custom colour table for your pixmap, then
*YES*, you *DO* have to create a custom GDevice. This is because the mapping
from the colours you ask for to actual pixel values is done using an inverse
colour table, and you find those in the GDevice structure, not in the PixMap.

Are you using the GWorld routines? If not, I highly recommend them. Here's how
you create a GWorld:

    Err := NewGWorld
      (
        MyGWorld, (* ptr to returned GWorld *)
        PixelDepth, (* number of bits per pixel *)
        BoundsRect, (* bounds of GWorld's PortRect *)
        CTable, (* custom colour table or NIL for default *)
        NIL, (* don't want to use an existing GDevice *)
        Flags (* specifying useTempMem puts pixmap into temporary memory *)
      )

You can read the rest in IM6. The GWorld routines really are easy to use.
Compatible, too.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
                       Signature tow-away zone. You have been wa

+++++++++++++++++++++++++++

From: [e-mail] (Matthew Hall)
Date: 11 Sep 92 21:28:09 GMT
Organization: Oberlin College Computer Science

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

>
>   >  This way, I can
>   > draw directly into the offscreen map since the positions of the colors
>   > in the clut don't change, and I don't have to use
>   > pmtolerant+pmexplicit, or setentries, and I can draw in an ideal color
>   > environment and let PM take care of tolerance and updates.
>
>   Hang on--you don't need a palette for an offscreen port. The main point of
>   palettes is for use with on-screen windows. The only point with attaching
>   a palette to an offscreen port would be so you can use PmForeColor and
>   PmBackColor to quickly specify colours from the palette. Tolerant and
>   animated entries don't mean anything in an offscreen palette.
>
I should have been clearer.  I load a 256 color pallette from a
resource file with GetCTable.  Then I set
Offscreen^.portpixmap^^.pmtable equal to that clut.  Then, I create a
palette for the current screen depth, and fill it with values from the
clut.  The palette is only for the window that the plot will
eventually be displayed in.  I draw in the offscreen pixmap by
directly setting the bytes.  If I loaded a gray scale, then the level
of gray is from 0-255.  I just place that byte in the pixmap data.
When I am done, I call copybits from the port to the screen.



>   What exactly *is* your method? If you're directly poking colour table
>   entries, are you remembering to call CTabChanged so QuickDraw knows what
>   you've been up to?

No I haven't.  I didn't even know I was supposed to.  Thanks.

>If you want a custom colour table for your pixmap, then
>  *YES*, you *DO* have to create a custom GDevice. This is because the mapping
>  from the colours you ask for to actual pixel values is done using an inverse
> colour table, and you find those in the GDevice structure, not in the PixMap.
>
>Are you using the GWorld routines? If not, I highly recommend them. Here's how
>   you create a GWorld:

The problem is that I want this to be compatible with as many
computers as it can.  GWorlds are only in sys 7 and 32 bit quickdraw
equipped Macs.  Inhibited colors are only in systems 6.0.5 and later.
I may be able to assume that anyone running color should be running
6.0.5, so maybe I will use inhibited colors, and just create one
palette, but I don't want to assume system 7, or 32-bit QD.
Of course, my compatibility concerns are worthless if my method
crashes most computers or graphics cards.  It works on an LC tho'

I guess I will have to create a gDevice for the offscreen port then.
The only quickdraw call I make, besides copybits, is fillrect though.
Otherwise I just poke in numbers.  it seems kind of a waste of memory
to create a GDevice just for FillRect when otherwise things seem to be
working well.  I can't see any problems with accelerator cards since I
don't modify screen data directly.

Thanks for the help
- -matt hall

- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


---------------------------

End of C.S.M.P. Digest
**********************